[00:03.210 --> 00:08.360]  Hello DEF CON, welcome to our talk DNS section.
[00:09.280 --> 00:17.080]  Today will be an interesting talk about DNS and the workings of the internet and cryptography.
[00:17.480 --> 00:26.040]  So what this talk is about is about an email privacy breach in the largest French cloud provider
[00:26.730 --> 00:32.560]  which is also the first practical attack on NSEC, DNS Secure Zone Working.
[00:32.660 --> 00:38.180]  And finally it's a cautionary tale about the use of hash functions.
[00:39.400 --> 00:46.240]  Why this matters is because DNS is everywhere, it's part of the internet, it's heavily used,
[00:46.240 --> 00:51.780]  it's very important and there are tons of potentially very valuable interesting data
[00:51.780 --> 00:59.140]  all over the place. The other reason why it matters is that zone working has not been demonstrated
[00:59.140 --> 01:05.260]  in the wild to this extent before and it's the first time that we actually recover very valuable
[01:05.260 --> 01:18.100]  interesting data from it. Who we are? Well this is Adrien. Hello! And I'm Rémy. We are from Ecole
[01:18.100 --> 01:24.880]  Normale Supérieure, PSL University in Paris, France, in the beautiful place itself. And this
[01:24.880 --> 01:31.620]  is not the first time that we talk at DEFCON. This has been done in collaboration with Amaury
[01:31.620 --> 01:40.340]  Barral and David Nekash. So without further ado let's start with the first part of our talk.
[01:44.780 --> 01:50.980]  So to understand DNS it's very important to understand our talk. We're going to start with
[01:50.980 --> 01:59.620]  that. The basic question that you ask with DNS is who is behind a website such as skytalk-vids.com
[01:59.620 --> 02:07.060]  for instance. So DNS, the domain name system, is a system to name remote resources, to give you
[02:07.060 --> 02:13.800]  access to them, and it does that by holding a distributed database. A system that contains
[02:14.360 --> 02:19.100]  record resources and domain names and that allows resolvers
[02:19.650 --> 02:25.600]  to figure out the translation between a domain name and an IP address.
[02:26.440 --> 02:32.860]  The DNS tree itself is subdivided into subtrees that are called zones and are
[02:32.860 --> 02:39.720]  administrated by different people, different entities, whose role it is to keep it up to date.
[02:39.720 --> 02:47.680]  So when you want to, say, build a website, create a new website, well, you actually need to go
[02:47.680 --> 02:52.680]  through several steps. Once you have a device and you have a server and you have a website running
[02:52.680 --> 03:01.400]  on it, you need to add your device, your IP address, to a DNS server. And to do that you
[03:01.400 --> 03:09.880]  call a registrar and you run a DNS server that advertises your IP in connection to the domain
[03:09.880 --> 03:15.010]  name that you are interested in. And you have to maintain all of this, of course.
[03:15.700 --> 03:20.700]  Most people do not want to go to such trouble to get their website running,
[03:20.700 --> 03:25.420]  and therefore they just pay someone to do the job for them,
[03:25.420 --> 03:32.680]  including getting all this working together. This is the spirit behind cloud hosting,
[03:32.680 --> 03:40.740]  which does provide the device, the hosting, the maintenance, and also the DNS registration and DNS
[03:41.260 --> 03:48.120]  publication. And this is the main thing we are going to talk about.
[03:51.840 --> 03:58.140]  Our target today is OVHcloud. They are the largest French cloud provider, by far,
[03:58.140 --> 04:04.220]  and second in Europe. And they sell all kinds of cloud-related services.
[04:05.500 --> 04:12.200]  In particular, they do sell domain names. And the basic plan for domain names include email
[04:12.800 --> 04:17.770]  redirects. Namely, it means you do not get a full email account, but you can redirect,
[04:17.770 --> 04:23.250]  contact at your OVHcloud domain to your usual Gmail account.
[04:23.330 --> 04:27.330]  And as a side note, they do host Wikileaks since 2010.
[04:29.610 --> 04:36.810]  So let's create an email redirect on the example domain. Here, dnssection.ovh,
[04:36.810 --> 04:44.150]  which we have just bought for the occasion. So in the admin panel, we just add a redirect from
[04:44.150 --> 04:54.830]  test.dnssection.ovh to target.yopmail.com and click confirm. And if we go look at the DNS zone,
[04:54.830 --> 05:01.450]  which we can also find in the admin panel, then we realize there is a new DNS record in there.
[05:01.690 --> 05:08.470]  If we zoom out this, then we can see that for test.dnssection.ovh,
[05:08.470 --> 05:13.850]  then you have a txt record with a target email, so target.yopmail.com.
[05:14.670 --> 05:24.730]  So this means that anyone in the world can just query test.dnssection.ovh and get the target of
[05:24.730 --> 05:31.170]  your email redirect. Obviously, it's not easy to get the whole database because you cannot ask
[05:31.170 --> 05:38.730]  the DNS server for the whole list of subdomains of at.dnssection.ovh.
[05:44.260 --> 05:50.960]  So why does it matter? Why do we care? Well, assume for a moment that we do manage to find a
[05:50.960 --> 05:57.740]  way to access this redirection database. It does contain a lot of interesting information. It's
[05:57.740 --> 06:04.000]  actually essentially client information for the users of this cloud hosting service.
[06:04.000 --> 06:09.760]  It includes emails, of course, but also names and potentially more information,
[06:09.760 --> 06:14.500]  billing information, for instance, with which we can be creative. We can actually
[06:14.500 --> 06:20.380]  start wondering, okay, what can we do with this information? Well, we can perhaps spam, we can
[06:20.380 --> 06:26.300]  try password dumps, we can perform social engineering on the basis of this information,
[06:26.300 --> 06:31.620]  we can perhaps find interesting information on the businesses that they hold, and so forth.
[06:31.620 --> 06:36.320]  So there's really a lot of ideas about what we can do with this information,
[06:36.320 --> 06:40.280]  and we will show you that in the latest part of this talk.
[06:42.420 --> 06:51.400]  So, well, let's try the naive way to do brute force to recover all the information using just
[06:51.860 --> 06:59.020]  a DNS query directly on the hosts that we are interested in. So the way we would do that is we
[06:59.020 --> 07:06.640]  get a list of OVH cloud-handled domains, we select those that we are most interested in,
[07:06.640 --> 07:14.540]  get a sublist, and we DNS query these domains. It works rather well for the domains that are
[07:14.540 --> 07:23.440]  hosted by OVH. And in doing so, we have two ways essentially to get an interesting redirect email.
[07:23.440 --> 07:30.000]  Either we look for the public email addresses, the ones that are displayed on the website,
[07:30.000 --> 07:35.560]  and we try to see whether they redirect to something interesting. This is one way. The
[07:35.560 --> 07:41.840]  other way is we don't really know what the real address is or whether they are redirects to begin
[07:41.840 --> 07:50.100]  with. So we, well, we try addresses we think are likely to exist, such as abuse at the domain,
[07:50.100 --> 07:57.980]  admin at contact at the domain. And in doing so, we, if we get a response,
[07:57.980 --> 08:03.820]  we get not only the existence of this particular email address that we just guessed, but also the
[08:03.820 --> 08:12.300]  corresponding target email redirect, which does not appear either on the website or in that case
[08:13.000 --> 08:18.960]  elsewhere. Of course, if you just try to do this, you're going to run into trouble
[08:19.500 --> 08:28.180]  because it's very likely that it is not stealthy to just query massively random DNS
[08:29.160 --> 08:35.180]  servers with random email addresses. So in practice, if you want to do this, you better be
[08:35.180 --> 08:42.400]  clever and avoid rate limiting by using several clients. But just for the sake of demonstrations,
[08:43.280 --> 08:50.120]  here we can do this from a single host using very simple low-tech devices, including
[08:50.800 --> 08:59.140]  bash and dig and just the file system. So really, we just run a first script that
[08:59.140 --> 09:07.140]  queries the DNS server to get a lot of interesting information about the domains. And then we dig the
[09:07.140 --> 09:15.060]  txt record, the one that contains the redirect in our case. So well, there's a demo for that.
[09:20.710 --> 09:28.270]  Okay, so let's look at this in action. You have here the bash script we just showed you.
[09:31.060 --> 09:41.510]  And we are going to run this very script right now. It will show addresses we just blurred them
[09:41.510 --> 09:47.730]  for privacy reasons. So on the left, you have the addresses that we query,
[09:47.730 --> 09:57.410]  and we recover the txt record on the right with the redirection email. This video is real-time,
[09:57.410 --> 10:05.270]  so it shows you that this is quite fast, in fact, quite efficient. And we do this from a single host
[10:05.270 --> 10:11.790]  here. But of course, you can parallelize this effort by calling several addresses at the same
[10:11.790 --> 10:25.810]  time. So what do we get? It does work. It does work. We do get information. So if we consider
[10:26.010 --> 10:34.910]  a subset of about 14,000 potentially vulnerable domains in the frtld, what we get is about
[10:34.910 --> 10:42.990]  15,000 email redirects, of which about 10,000 unique email addresses, something we didn't have
[10:42.990 --> 10:50.150]  before. So this is extremely interesting. But you might say, well, we used public emails or
[10:50.150 --> 10:57.830]  easily guessable emails, and we found private redirection emails. So well, perhaps, I mean,
[10:57.830 --> 11:03.930]  it's interesting, but what are we not seeing? What are we missing from the picture? And that's
[11:03.930 --> 11:16.130]  where DNS section comes into play, really. So what we are going to do is we are going to use
[11:16.130 --> 11:24.070]  DNSSEC. DNSSEC is in itself a very interesting topic and a very large one. If we want to go into
[11:24.070 --> 11:30.550]  details, we might as well do a talk entirely on the topic and perhaps even several talks. So
[11:31.170 --> 11:36.770]  very short summary, what you should know about it is that DNS itself is insecure if you use it like
[11:36.770 --> 11:43.750]  it, just like this. So you need extensions, which are provided for most of them by DNSSEC.
[11:43.970 --> 11:50.770]  Every modern good implementation of a DNS server does have support for DNSSEC and so do
[11:50.770 --> 11:57.230]  resolvers. Essentially, what DNSSEC does is it provides a route of trust and a tree derivation
[11:57.230 --> 12:03.610]  scheme that use public key cryptography, digital signatures to ensure authenticity. So you know
[12:03.610 --> 12:08.610]  that you are really talking to the server you think you are talking to and that the information
[12:08.610 --> 12:16.730]  provided there is at least the one that it commits to sending. So it requires cryptographic
[12:16.730 --> 12:24.890]  elements and it requires sometimes some lockpicking skills, as perhaps the recent enough
[12:24.890 --> 12:31.650]  incident depicted here shows, if you know what I'm talking about. If not, look into what happens
[12:31.650 --> 12:40.090]  in a key rollover session of DNSSEC. So we can look at this, we can look at the information
[12:40.090 --> 12:53.490]  sent to us by a DNSSEC compatible server. One tool that we can use to recover information
[12:53.490 --> 13:03.370]  about DNSSEC is DNSViz. It is available in your favorite browser at dnsviz.net.
[13:05.370 --> 13:12.550]  So here we apply it to dnssection.ovh, which is the website we use for demonstration
[13:12.550 --> 13:21.010]  purposes during this talk. It has been slowed down so I can comment on it. It is actually much faster
[13:21.010 --> 13:31.740]  than this. It queries all the interesting information about the DNS records here
[13:31.740 --> 13:36.260]  and we can see the full chain of trust for the domain.
[13:37.360 --> 13:45.400]  So in particular we can see all the cryptographic information, the algorithm in use and we can also
[13:45.400 --> 13:57.160]  see some of the common sub-records that appear in the DNS zone. SOA, TXT, MX, NS and A records.
[13:58.120 --> 14:05.820]  You can also see which algorithms have been used. In this particular case, dnssection.ovh
[14:05.820 --> 14:21.250]  uses DNSSEC with algorithm 8, RSA plus SHA 265 with NSEC3. And you can go up to the OVH
[14:21.250 --> 14:29.650]  and above zones and see how things are derivated from the root of trust. Here you can see .ovh
[14:29.650 --> 14:37.250]  switching from algorithm 8 to algorithm 13, one of the 2020 goals for AFNIC.
[14:39.010 --> 14:46.230]  DNSviz also checks for errors. Try it on Defcon.org, you will be surprised.
[14:46.530 --> 14:52.570]  Unless of course the goons have watched our talk in advance and have already fixed it.
[15:02.710 --> 15:10.410]  Let us dive in a fundamental obstacle of DNSSEC. Issues with negative responses.
[15:11.090 --> 15:16.610]  For positive responses, it's quite easy. If you want to authenticate that the record example.com
[15:16.610 --> 15:25.710]  is at IP 1.2.3.4 exists, then it's quite easy. You just affix your signature to it.
[15:25.710 --> 15:30.770]  But if you want to authenticate that there is no record for bad.example.com,
[15:30.770 --> 15:38.130]  this is much trickier. You obviously cannot put every negative possibility signing in the zone.
[15:38.610 --> 15:41.090]  This is where NSSEC comes to the rescue.
[15:42.990 --> 15:49.330]  NSSEC is much more trickier and complicated than what I'm going to explain here, but all you need
[15:49.330 --> 15:56.490]  to understand is the principle depicted in this slide. So basically NSSEC signs
[15:57.450 --> 16:03.590]  intervals where there is no domain. For example, it could sign there is no domain
[16:03.590 --> 16:12.050]  between apple.example.com and carrot.example.com in lexicographical order and therefore it means
[16:12.050 --> 16:18.430]  that bad.example.com cannot exist because B is between A and C.
[16:20.070 --> 16:29.210]  And it does create a big issue so that you can now enumerate all records in the DNS zone.
[16:29.210 --> 16:36.390]  How to do that is quite easy. Just pick a random name, for example fgfrd.example.com
[16:36.390 --> 16:44.350]  and query the DNS server for it. Obviously fgrd does not exist, it's a random name,
[16:44.350 --> 16:51.010]  it will enter the interval associated with it and so here it tells you that there is nothing
[16:51.010 --> 16:58.450]  between carrot.example.com and good.example.com. Very good, we have just found two subdomains
[16:58.450 --> 17:06.050]  of example.com. We just repeat with a successor of good, here good A, get another name,
[17:06.050 --> 17:12.950]  another interval, and loop until we've found every positive record in the zone.
[17:12.950 --> 17:20.210]  So it means that it is trivially doable for an attacker to get the whole DNS zone
[17:20.210 --> 17:30.210]  of an NSEC-enabled domain. So now you might be thinking okay that's what we're gonna do,
[17:30.210 --> 17:35.290]  we're just gonna use NSEC zone walking. No, that's not what we're gonna do,
[17:35.890 --> 17:40.750]  because NSEC zone walking doesn't work. It doesn't work anymore in the real
[17:41.410 --> 17:48.690]  world for the simple reason that no one uses NSEC at all anymore. Yes, you can be sad about this,
[17:48.690 --> 17:52.170]  it's not what we're gonna do. We're gonna do something more clever,
[17:52.170 --> 17:55.710]  although not very different, so that's why we talked about it.
[17:57.970 --> 18:05.130]  What we're gonna do is zone walking with NSEC 3. NSEC 3 has been designed and implemented and
[18:05.130 --> 18:11.530]  deployed for the very reason of providing resistance against zone enumeration, the way
[18:11.530 --> 18:18.490]  we just described for NSEC. So it's a patch on NSEC. In a nutshell, what it does is instead of
[18:18.490 --> 18:26.190]  having the records in plain text, they hash them using several repetitions of the SHA-1 algorithm,
[18:26.190 --> 18:35.070]  usually with sort or without sort. So the idea is it should hide the contents of the DNS records,
[18:35.890 --> 18:40.890]  and assuming you cannot do anything with hash values, well, you don't get access to them,
[18:40.890 --> 18:46.630]  you cannot enumerate. The truth is you can still dump the hash itself, so you can still
[18:46.630 --> 18:53.470]  do zone walking, you can still extract the hashes, it still kind of works. And NSEC 3
[18:53.470 --> 19:00.690]  is really what is deployed today in the real world, so that's what we are going to attack.
[19:05.050 --> 19:12.170]  As Remy just explained, the assumption behind NSEC 3 is that reversing even partially the hash
[19:12.170 --> 19:18.870]  is difficult. Well, in practice, it turns out it's not really true. You've probably heard about
[19:18.870 --> 19:25.610]  many people trying to break hashes, especially for passwords, and breaking hashes is even basically
[19:25.610 --> 19:36.750]  how you mine Bitcoin. So I think I'm hearing laughs in the Bitcoin mining farm when they hear
[19:36.750 --> 19:46.910]  that SHA-1 cannot be reversed. So in practice, for DNSSEC, you can find off-the-shelf readily
[19:46.910 --> 19:54.890]  available tools to crack the NSEC 3 hashes. However, to the best of our knowledge, it has
[19:54.890 --> 20:03.910]  never been used to dig valuable data. They only use that for the same demo, which is finding the
[20:03.910 --> 20:11.530]  list of subdomains of .com or .org, but most of the time the list of valuable domains is
[20:11.530 --> 20:24.470]  better found using Google or your favorite search engine. Okay, so let's show you the NSEC 3
[20:24.470 --> 20:32.530]  Volcker tool, which is used to get the hashes from the domain zone. This is actually a collection
[20:32.530 --> 20:42.330]  of scripts. Here we call the script collect of NSEC 3 Volcker on our dnssection.ovh domain.
[20:46.680 --> 20:55.540]  It starts by getting the NSEC 3 parameters, which are the salt and the number of SHA-1 iterations.
[20:56.980 --> 21:05.560]  Then, it is going to crawl through it and try 100 domains to find the intervals as we have explained
[21:05.560 --> 21:18.360]  in the previous slides. This video has been slowed down a lot. In practice, with a good network,
[21:18.360 --> 21:27.700]  this is actually really fast. You even get a progress bar from the tool. Here, the zone is
[21:27.700 --> 21:35.860]  quite small, so we get all the hashes very quickly. If you want to dump a TLD zone, I mean
[21:35.860 --> 21:49.290]  top-level domain zone, such as .org, then it takes much much more time. Another tool, NSEC 3 map,
[21:49.290 --> 21:56.190]  also exists and has advanced features, such as parallel queries and automatic conversion
[21:56.190 --> 22:04.450]  for Hashcat and John the Ripper. Unfortunately, it has been written in Python 2, which is in the
[22:04.450 --> 22:11.950]  process of going extinct. So, use whichever tool you feel more comfortable with.
[22:14.640 --> 22:22.000]  Well, so we have just dumped all the hashes of dnssection.ovh. What do we do now? Well,
[22:22.000 --> 22:27.820]  we bring out the GPU rig. Unfortunately, we don't have a whole datacenter.
[22:27.820 --> 22:34.500]  We only have a nice Tesla P100. If you know nothing about GPUs, let's just say this is not
[22:34.720 --> 22:44.240]  a potato GPU. Most of you have heard about Hashcat before. This is the standard tool
[22:44.240 --> 22:51.660]  to break hashes. So, let us just feed the output of NSEC 3 to Hashcat and try different
[22:51.660 --> 22:56.720]  kind of attacks, such as dictionary attacks and brute force attacks.
[22:59.380 --> 23:08.220]  Here, we show you a little demo of Hashcat. In this case, this is a simple brute force of all
[23:08.220 --> 23:16.020]  lowercase alphanumeric emails of exactly five characters, as you can see on the command line.
[23:20.470 --> 23:29.970]  First, Hashcat displays some information about the GPU and compiles the OpenCL NSEC3 kernel
[23:29.970 --> 23:38.370]  tailored for your GPU. Then, it starts the hash cracking process.
[23:39.150 --> 23:47.830]  In this case, we only run it on a small subset of our findings. The video has been sped up
[23:47.830 --> 23:55.630]  to avoid audience boredom. You can see a few hashes being reversed on the screen.
[23:55.870 --> 24:09.400]  Again, we blurred the result for privacy reasons. As a side note, we have found a bug in Hashcat.
[24:09.700 --> 24:17.220]  Dots were not handled correctly. Many emails contained dots in the left part,
[24:17.220 --> 24:24.720]  so this proved to be a serious concern for us. We made a dirty fix for ourselves,
[24:24.720 --> 24:30.580]  and the Hashcat team has since fixed it properly. Thanks a lot to them.
[24:33.220 --> 24:42.640]  Let us consider about 16,000 interesting DNSSEC hashed records. Well, using our GPU,
[24:42.640 --> 24:48.140]  we were able to unhash as much as 88% of them, so that's quite a good result.
[24:48.800 --> 24:54.340]  Let's see a little breakdown of our results. So, in three quarters of the cases,
[24:54.340 --> 25:00.240]  we were able to reverse the hash, and we did find an interesting email redirection.
[25:00.360 --> 25:06.600]  In 14%, we did reverse the hash, but it was something else, such as an FPF record.
[25:06.640 --> 25:11.700]  And in the remaining 12%, well, we were not able to unhash.
[25:12.460 --> 25:17.720]  By God's thing, the remaining ones are mostly domain key records,
[25:17.720 --> 25:21.780]  which are not descriptible for email redirections.
[25:23.080 --> 25:30.480]  A little disclaimer, we are not here to dox people, so obviously, all people names and
[25:30.480 --> 25:40.740]  domain names in the following example have been modified. Let's look at a few statistics.
[25:41.520 --> 25:51.000]  So, first, we can just classify the target of the redirection by the email provider they use.
[25:51.140 --> 25:57.700]  I think you can guess which email provider is used by most webmasters, and this is obviously
[25:57.700 --> 26:07.420]  Gmail.com. And then, if you look at the left part of the email, well, it does leak the name
[26:07.420 --> 26:15.320]  of the people quite often, because, well, most emails are your name at something,
[26:15.320 --> 26:25.380]  not your country. So it happens that, in practice, the name of the person is found in the email in
[26:26.060 --> 26:32.480]  about half the time. However, this doesn't mean that we found some private information
[26:33.100 --> 26:37.020]  on some website, where people happily say that they do run the website.
[26:37.420 --> 26:44.640]  So we try to find out how often we could not find the name in the target of the redirection
[26:44.640 --> 26:50.880]  on the website. Well, this is in about two-thirds of the time. So, in two-thirds of the time, when
[26:50.880 --> 26:58.180]  we have a name in the target of a redirect, then this was not something we could have easily found
[26:58.180 --> 27:05.940]  on website. So we have leaked some private information. A little more complicated is
[27:05.940 --> 27:14.340]  how often this email would not appear in a Google search. And in practice, this is about half of the
[27:14.340 --> 27:21.900]  time. So this means that there are a lot of emails that are not publicly available, and we did,
[27:21.900 --> 27:30.260]  again, find a lot of private info using them. The last thing was a little more difficult to
[27:31.120 --> 27:37.020]  identify. And this is about a business connection, conflict of interest, or fake
[27:37.020 --> 27:45.600]  competitors. And using the redirection we found, well, we were able to find such things in about
[27:45.600 --> 27:54.340]  one-quarter of the cases. A little homework for you, that we have not tried, is run the found
[27:54.340 --> 28:01.980]  emails for the haven't-been-pwned database, and find how many of them do have an entry in it.
[28:03.860 --> 28:11.940]  What if we try to dox a scam on an adult website? Well, first, please don't tell my wife about it.
[28:12.340 --> 28:19.120]  Well, we did try to find some names or some business connections, but they are very clever,
[28:19.120 --> 28:23.720]  and it's actually a fail. Their email never discloses their name.
[28:23.800 --> 28:28.460]  But we still have the email, so who's the scammer and who's the scammer.
[28:30.720 --> 28:36.480]  Anything more serious? Well, we did find some famous people emails, like politicians
[28:37.040 --> 28:44.960]  and showbiz people, which have their own Wikipedia page. We also found a few emails of
[28:44.960 --> 28:51.920]  activists, and on a much lighter note, we did find a lawyer website with a redirect to,
[28:51.920 --> 29:00.820]  guess what, mylittlepony.hisbirthdate at gmail.com. And also, we found 50 people who
[29:00.820 --> 29:07.000]  had added redirects for the no-reply at other domain. Why would they do that?
[29:08.740 --> 29:15.020]  A little caveat, this is actually some manual analysis. We went through hundreds of websites
[29:15.020 --> 29:19.780]  phishing for the names and the emails. So typically, this means going through the contact
[29:19.780 --> 29:24.980]  page, googling the name, googling the emails, and dealing with obscene stuff such as adult
[29:24.980 --> 29:31.940]  flash websites, which are really difficult to navigate through. So this is all by best effort,
[29:31.940 --> 29:43.440]  and we might have missed some public data. So okay, we found a lot of interesting information.
[29:43.440 --> 29:51.080]  Some of it apparently does not appear either on the website or in Google, and very likely was
[29:51.080 --> 29:57.620]  information that was not meant to be made public. So we thought it was an interesting issue. We
[29:57.620 --> 30:04.480]  tried to bring it up to OVHcloud. So we called the hotline, and we're going to tell you about
[30:04.480 --> 30:09.780]  the disclosure process. So we called the hotline, and we said, okay, we think we have a problem
[30:10.560 --> 30:19.920]  with your handling of private data. They say, send an email to abuseat. Okay, so we write the email,
[30:19.920 --> 30:25.020]  and we include the technical details, some of which we just shared with you right now,
[30:25.020 --> 30:33.300]  and we never got a reply. So well, we were a bit puzzled. Perhaps we did not understand
[30:33.300 --> 30:39.980]  what they meant by send an email. So we called them again, and calling them again, they say, yes,
[30:39.980 --> 30:44.540]  do send an email to abuseat. You did the right thing. Just do it again. Perhaps they missed it.
[30:44.540 --> 30:50.700]  So okay, well, we write a second email, and we never got a reply.
[30:52.600 --> 30:59.540]  So at that point, what we tried is to contact people working there, try to ping the right
[30:59.540 --> 31:05.900]  person, and to try and get them to forward our email internally to the right people.
[31:07.020 --> 31:12.480]  Well, to this day, we are still waiting for a response. So OVH, if you are looking at us,
[31:12.480 --> 31:22.290]  we tried. Okay, so if you want to fix it, what should you do if you do not want to be
[31:22.810 --> 31:29.130]  targeted by the kind of enumeration and privacy disclosure that we just described?
[31:29.690 --> 31:36.710]  Turns out that this has been a goal of NSEC for many years now. This was the reason why
[31:36.710 --> 31:44.530]  NSEC 3 was proposed, and obviously NSEC 3 failed. But the real, the correct answer
[31:45.090 --> 31:52.410]  to this is use public key cryptography. It's been described in two RFCs how to do this with
[31:52.410 --> 31:59.390]  NSEC, in a way that's compatible with the NSEC. And there are two leading implementations of this
[31:59.390 --> 32:08.730]  idea. One is NSEC 5, which is already six years old now. And the other is to use NSEC 3 but replace
[32:08.730 --> 32:18.310]  the hash by a public key signature, a digital signature. The problem is NSEC 5 was met with
[32:18.310 --> 32:24.550]  skepticism in the first draft, and the draft has not been finalized, and it has not been standardized,
[32:24.550 --> 32:30.850]  and it brings latency into the game. But most importantly, NSEC has a bad track record. This is
[32:30.850 --> 32:38.070]  already the fifth iteration of it, and you have not heard of NSEC 2 or NSEC 4 in this talk, and
[32:38.070 --> 32:46.070]  you might wonder why. Well, perhaps they never got to see the light for good reasons. The alternative
[32:46.070 --> 32:55.450]  is NSEC 3, NSEC 3 with digital signatures. And today that means ECDSA algorithm 13 in the DNS
[32:55.990 --> 33:04.310]  SEC documentation, mainly because it is the only one that can be used in this list,
[33:05.330 --> 33:12.450]  because it signs fast and the signatures are small enough that it is actually practical to use.
[33:13.130 --> 33:19.570]  But it's on a fixed curve with a fixed hash function, and it's a bit of an old algorithm,
[33:19.570 --> 33:26.830]  to be honest, which makes, amongst other issues, resolvers carry the burden. The fact that
[33:26.830 --> 33:33.070]  resolvers now have to perform signature verification, which is actually quite slow.
[33:33.470 --> 33:39.570]  It also requires very careful implementation and handling of algorithms and keys, because ECDSA
[33:39.570 --> 33:47.570]  is famously brittle. An experience in the matter shows that DNS servers are, well,
[33:47.570 --> 33:53.510]  historically bad at it. We gave you a reference on the slide that you can look into
[33:54.030 --> 34:04.870]  about the handling of RSA keys in the past. Remy has just explained you how to fix DNSSEC,
[34:04.870 --> 34:12.490]  but most people do not want to handle their DNS zone by themselves, and thus use cloud hosting.
[34:12.730 --> 34:19.630]  So, assume for a second that you are an OVHclose customer, and you are using their redirection
[34:19.630 --> 34:27.790]  features. How can you protect yourself right now? Well, there are two different things to protect.
[34:27.870 --> 34:33.790]  First, the target of the email redirection. An easy way to hide the real target email
[34:33.790 --> 34:43.970]  is to use double redirects. Let me explain. First, redirect test.dnssection.ovh
[34:43.970 --> 34:54.890]  to test.dnssection.gmail.com in the OVHcloud admin panel. Then, in your Gmail interface,
[34:54.890 --> 35:03.510]  redirect test.dnssection.gmail.com to your personal email address. An attacker will only
[35:03.510 --> 35:09.530]  be able to see the first redirect, and thus will not learn anything useful.
[35:10.210 --> 35:16.750]  Second, you want to protect your domain email list. This is actually quite tricky.
[35:17.850 --> 35:26.070]  What about disabling DNSSEC entirely? Well, there is a reason DNSSEC exists,
[35:26.070 --> 35:32.130]  and dropping the security properties of DNSSEC might not be worth it. Or you may also have
[35:32.130 --> 35:39.010]  services for which DNSSEC use is a must. Another possibility to protect the list
[35:39.010 --> 35:45.930]  would be to use long and unpredictable emails, so the hash is almost impossible to reverse.
[35:46.570 --> 35:54.870]  For online websites, this works quite well. The web server does not care much. However,
[35:55.070 --> 36:00.150]  a long and non-human friendly email is not going to make a good first impression
[36:00.150 --> 36:08.290]  on your business card. If your domain email list is especially sensitive, the best way out is
[36:08.290 --> 36:15.570]  probably to stop using vulnerable OVHcloud redirection for now. Upgrade to an OVHcloud plan
[36:15.570 --> 36:24.370]  with real email addresses. So, well, that brings us to a conclusion for this talk,
[36:24.370 --> 36:30.390]  which will be rather fast, because you heard most of what we had to say already.
[36:30.390 --> 36:38.330]  The lesson to remember, do not store private information in your DNS zone if you do not have
[36:38.330 --> 36:47.270]  to. This is likely to leak unless, well, countermeasures are widely deployed. DNSSEC and
[36:47.270 --> 36:52.930]  SEC3 attacks exist. They are practical and they can reveal information that was not obtained in
[36:52.930 --> 37:02.110]  any other way that we know of. So try to push your local representative for DNS server to adopt
[37:02.110 --> 37:11.270]  modern countermeasures against zone enumeration. NSEC5 is not yet final. Try to push for it.
[37:11.270 --> 37:18.810]  And adoption of ECDSA as a signature for zone enumeration is also on the way. But, you know,
[37:18.810 --> 37:25.310]  it's taking time. So try and get there. That's all we had to say. And do have a look
[37:25.310 --> 37:30.150]  at the Proof of Concept website that we put up for you to play with.
[37:31.450 --> 37:38.990]  Thank you again. Have a great day and try this at home. Very carefully, of course. Bye-bye.
